%
% Copyright (C) Håkan Lindqvist 2006, 2007.
% May be copied freely for educational and personal use. Any other use
% needs my written consent (i.e. no commercial use without my approval).
%

% Security policies.
\label{security policies}
\label{chapter:policy}
\index{security policy}

Upon the decision of constructing a secure system, or making an existing
system secure, there are several issues that must be handled. First one
will have to determine what is considered secure, what threats that have
to be addressed and formulate the decisions that are reached in a way
that is as unambiguous as 
possible~\cite{Andersson, Bishop, SecureCoding}. Preferably this is done
at the design phase upon the construction of the to be \texttt{system}.
The goal in this phase is to identify the secure and insecure states
that describe a secure system, as is defined in 
Definition~\ref{definition:secure system}. The identifications of
threats to the system may be done in a formal manner using for example
threat trees~\cite{Amoroso, Andersson}. 

This chapter will start with a presentation of the basic definitions
needed to discuss the theory constituting the basis for security policies in
a consistent manner. Then some general theory is presented and the
chapter is finished with a discussion of security as a process and
provide examples of three security policy models.

%%%%%%%
\section{Definitions used in security policy theory}
To be able to discuss the field of security policies exactly, it is
necessary to introduce definitions of the terms used. First, it is
important to know the difference between \texttt{policy} and
\texttt{mechanism}~\cite{Bishop}.

\begin{definition}
\label{definition:security policy}
\index{definition!security policy}
A \texttt{security policy} is a statement that partitions the states of
the system into a set of \texttt{authorized}, or \texttt{secure}, states
and a set of \texttt{unauthorized}, or \texttt{non secure} states.
\end{definition}

Again, note the the use of states to define when a system is to be
considered secure. Remember that the states referred to are some set of
actual settings in a \texttt{system} that has been selected to represent its
state, such as the \texttt{objects} that \texttt{subjects} are
accessing at a given time or the amount of processing power supplied to
an \texttt{entity}.

\begin{definition}
\label{definition:security mechanism}
\index{definition!security mechanism}
A \texttt{security mechanism} is an entity or procedure that enforces
some part of the security policy.
\end{definition}

Informally that translates to that a \texttt{security policy} is the
specification of how a system should maintain a secure state, and what
is considered a secure state, while a \texttt{security mechanism} is a
part of the actual implementation enforcing the specification. This is
the same difference as in software development between the design and
the implementation stages.

When a security policy is defined, it is usually tailored to the needs
of a certain organization. Therefore different policies will have
different focal points among the fundamental properties of a secure
system (cf. Section~\ref{basics:fundamental components}). Many of the
more traditional policy models focus on the integrity and/or the
confidentiality of a system's information. One such example is given in
Section~\ref{policy:BLP}.

%%%%%%%
\section{Security as a process}
\index{security policy!as a process}
It is all too easy to see a ``secure system'' as a product. But the
truth is that it is more correctly seen as a process. If the bugs
discovered in software, and the security advisories that will follow
upon these, are taken into account, one easily understands that no system
will be perfect from its conception.

In previous chapters, formal security in the terms of states and
assignment of access rights have been considered. In a real world
problem, those issues often come down to the following steps
(adapted from material presented in~\cite{Bishop, Andersson}):

\begin{enumerate}
 \item Determine which of the three categories \texttt{integrity},
 \texttt{confidentiality} \\ and \texttt{availability} that are relevant
 for the system

 \item Identify threats to the relevant categories, using for example
 threat trees

 \item Formulate a policy that ensures that protects against the threats
   identified in the previous step

 \item Check the policy's completeness (cf. Section~\ref{chapter:tcb})

 \item Implement the policy in the system

 \item Verify the implementation (cf. Section~\ref{chapter:tcb})
\end{enumerate}

This process may be iterated several times as new threats are
identified, the policy is revised or that new rules are set by the
management.

It may appear very simple to perform these steps, but it may require
quite large amount of work to determine the threats present to a
\texttt{system} in a real environment, which can be very different
depending on who is using it, and then categorizing them in a consistent
manner. 
%
Moreover, there is always the risk of formulating a policy that is
either too restrictive or, on the converse, too non--restrictive.

%%%%%%%
\section{Formulation of a security policy on an organizational level}
\index{security policy!organizational level}
In the previous section, the process of formulating a security policy
and implementing was briefly described. This section will attempt to
provide some insight to the problems that are introduced when a security
policy should be formulated in an organization. As in most problem
areas, communication is the most important aspect to consider. The
arguments presented herein is in whole based on the organizational
theories presented in~\cite{Org}.

%
\subsection{Organizational issues when defining a security policy}
As has been previously stated, the purpose of a security policy is to
define what should and what should not be allowed in an organization. To
ensure that this is properly done, the process of defining a security
policy should incorporate information from all parts of an
organization that will access a \texttt{system}. This is important to
ensure that the formal restrictions that may be apparent on different
levels of the organization are imposed by the formulated policy. 


However, most organizations have an hierarchy that defines the
responsibilities of a member and a related set of rules for how
information should flow within that hierarchy. Such information may be
the policy portions that a department wishes to include in a security
policy. Hence, to ensure a correct and efficient formulation of a
complex policy, the organization must have a good communication
infrastructure.

That enough information from each part of an organization is crucial
becomes apparent if one considers that the resulting policy should
neither impose too much restrictions, since that will affect productivity
in a negative way, or be too loose, which will render the policy
ineffective. 

The collected information should be given to a designated section
within the organization to formulate a resulting policy, which then can be
implemented. Or course, a security policy can be implemented using a
mixture of \texttt{security mechanisms} and rules that members of the
organization are required to follow. 

Another reason to request information from different section of an
organization's hierarchy is that it will at least give the members of
the organization the impression of that they had a chance to influence what
the policy will govern. This will lessen the resistance towards the
policy once in place. It will also provide the management, which in the
end is responsible for the results of the policy, information on how
members of the organization feel about certain issues and what portions
of the policy that might need well formulated motivations; rules that
seem to be superfluous or counterproductive will be ignored whenever
possible.


%%%%%%%
\section{Examples of security policy models}
The examples presented below range from very classical to more recently
developed models. It is important to understand that these models do not
make up a policy on their own, a system will need classification of its
\texttt{principals} to make these work as intended. 
% The specification model for each of these models may range all the way
% from \texttt{DAC} to \texttt{MAC}.

%%%%%%%
\subsection{The Bell--Lapadula Model}
\label{policy:BLP}
\index{security policy!BLP}
\index{BLP|see{Bell--Lapadula}}
\index{Bell--Lapadula}
The \texttt{Bell--Lapadula Model} (\texttt{BLP})~\cite{Bishop} is of
traditional military orientation in that it is primarily concerned with
maintaining the confidentiality of a system's information.

The central point in the \texttt{BLP} is that all \texttt{objects} have
associated security labels and that all \texttt{subjects} have a
clearance level. By comparing the clearance with the security labels,
access is granted or denied. Since the \texttt{system} clears of denies
an access, the security model describes a \texttt{MAC} \texttt{system}.
The clearance and security labels are typically made up of sets on the
form:
\begin{displaymath}
  \texttt{(classification level, \{categorization code(s)\})}
\end{displaymath}
An example might be:
\begin{displaymath}
  \centerline{\texttt{(TOP SECRET, \{EU, US\})}}
\end{displaymath}
for a document classed as ``Top secret'' and relevant to both Europe and
the US.

To understand the idea underlining the model, the \texttt{dominate}
operation is presented as it is adopted from Bishop~\cite{Bishop}:

\begin{definition}
The security level $(L, C)$ dominates the level $(L', C')$ iff 
$L' \leq L$ and $C' \subseteq C$. A \texttt{subject} or \texttt{object}
is said to dominate another \texttt{subject} or \texttt{object} if its
associated security level dominates the other.
\end{definition}

By using the dominate relation, properties can be defined such that only
information that a \texttt{subject} has clearance to read can be
accessed, and make downgrading of a piece of information's security
classification impossible. The two are:

\begin{definition}
\textbf{Simple Security Condition (No read up)} \\
A \texttt{subject} $S$ can only read an \texttt{object} $O$ iff
\texttt{$S$ dominates $O$} and $S$ has discretionary access to $O$.
\end{definition}

``Discretionary access,'' means that the access rights associated with
the \texttt{object} allow that \texttt{subject} to access it
(cf. Section~\ref{chapter:access control def} for more information about
access control).

\begin{definition}
\textbf{*--Property (No write down)} \\
A \texttt{subject} $S$ can write to  an \texttt{object} $O$ iff
\texttt{$O$ dominates $S$} and S has discretionary access to $O$.
\end{definition}

This policy, if correctly enforced, will absolutely maintain the
confidentiality of any data in a system. Bishop~\cite{Bishop} discusses
this model to some length, as well as presenting a few of the more
common critiques against it.

%%%%%%%
\subsection{Domain Type Enforcement}
\label{policy:DTE}
\index{security policy!DTE}
\index{DTE|see{Domain Type Enforcement}}
\index{Domain Type Enforcement}
In a system using \texttt{Domain Type Enforcement} (\texttt{DTE}) for
access control, an access decision to a \texttt{subject} or
\texttt{object} is based upon
what domains the involved \texttt{subjects} have, and which types the
involved \texttt{objects} have been assigned~\cite{usenix_dte_unix_prot,
usenix_dte_root}.
Accesses are also controlled by controlling which accesses over domain
boundaries \texttt{subjects} are allowed to make and which types
\texttt{subjects} from a certain domain is allowed to access. Expressed
in a more casual manner, \texttt{subjects} are restricted in their
access to a set of \texttt{objects} of approved types.

A real world example of such a policy is given in 
both~\cite{usenix_dte_unix_prot} and~\cite{usenix_dte_root}. 
In~\cite{usenix_dte_unix_prot} examples of how the network security is
hardened is given, and in~\cite{usenix_dte_root} a policy that hardens a
system's integrity and confidentiality against some well known attacks
and some untrusted applications is presented.

That is, \texttt{DTE} is used to model which accesses are allowed on
what is considered an appropriate type and domain classification of all
\texttt{principals} in a system. Exactly what policy it enforces depends
on which transitions over domain boundaries that are allowed and from
which domains \texttt{subjects} may access \texttt{objects} of different
types and with which rights they may do so.

The principal ideas behind this have strong similarities with the
Schematic Protection Model presented in Section~\ref{SPM} in that types
of different kinds are associated with all entities in the system and
access decisions are based upon those types and a set of rules for
interpreting the context upon an access attempt.

%%%%%%%
\subsection{Role Based Access Control}
\label{policy:RBAC}
\index{security policy!RBAC}
\index{RBAC|see{Role Based Access Control}}
\index{Role Based Access Control}
An approach that has increased in popularity is to associate access
rights to \texttt{roles} instead of \texttt{subjects}. That is, a
\texttt{subject} may assume several roles over time, and have access
rights changed automatically as transitions are done. It is also
possible to make \texttt{Role Based Access Control}
(\texttt{RBAC})--system~\cite{rbac_base, rbac_conf}
 behave as systems using more traditional access
control measures, such as pure \texttt{Identity Based Access Control}
(\texttt{IBAC}, cf. Definition~\ref{definition:DAC}).

In a common model named RBAC96~\cite{rbac_conf}, the following
components are used to define roles and their associated access rights:

\begin{enumerate}
 \item The set of users \\
       The set of regular roles and the set of administrative roles \\
       The set of regular permissions and the set of administrative
       permissions \\
       The set of sessions

 \item A relation for assignment of rights to regular roles and another
 relation for assignment of rights to administrative roles

 \item A relation for assignment of roles to users

 \item A relation for assignment of administrative role to users

 \item A partially ordered hierarchy of roles (i.e. like a lattice)

 \item A partially ordered hierarchy of administrative roles (i.e.  like
   a lattice)

 \item A function that maps any session to a single user associated with
 that session. \\
 Another function that maps a session to the set of roles and
 administrative roles associated with it at a given point in time. The
 associated set may change over time

 \item A number of constraints that will be used to determine which
 values in the above mentioned sets that are allowed
\end{enumerate}

The idea is to associate a user with a session, and then bind that
session to a role, that may change over time, which will be used to
associate the user with the rights that are appropriate.

By the introduction of a hierarchy of rules, the concept of inheritance
can be used to make more powerful roles inherit the rules of less
powerful ones. A typical example is the relation between an engineer
and a project's manager. The manager will both need to be able to
access data that the engineer has access to as well as data that are of
more administrative nature, which means that the rights that should be
associated with the manager role encapsulates the rights that are
associated with the engineer role. The presentations in~\cite{rbac_base,
rbac_conf} have many good examples and discussions on the topics briefly
mentioned here.

To summarize, \texttt{RBAC} models what rights can be given to which
\texttt{subject} by associating a certain role to it and which access
rights that are to be allowed are associated with that role. The policy
that it enforces is based upon those assignments.

One of the greater benefits of using this model is that it becomes very
easy to change the rights associated with a particular user in the
system, since the only action needed is to change the role that user has
for the moment. For the same reason it becomes easy to appoint new
people to new positions, since all access rights associated with the
tasks involved for a special position are associated with that position's
role, not with a particular
user. This makes revoking rights for the user that previously had that
role in the system and assigning them to the newly appointed a simple
task, simply change the roles for each of them.

